Existing hotel and travel computerized reservation systems use a top down search approach, creating single availability cells as they are discovered from the search request. For example, such systems may allow a user to input search criteria, such as the identity of the hotel, the check-in date, and the check-out date, to discover available hotel rooms for the selected number of nights (i.e. Single Length of Stay). Only after the product items (i.e., hotel rooms) are found is business logic applied to find rates and availability for the specific set of product items.
This prior art approach has several disadvantages. Because of the top-down nature of this approach, the product items (e.g., sellable rooms) need to be searched for and discovered with each request. Further, the search request must have as a minimum a hotel name/code, a check-in date and a check-out date. The availability request will be rejected if these minimum elements are not in the request.
Moreover, the core service of the prior art approach only allows for one hotel to be checked at a time, and given that the check-in and check-out dates are used in the search, the rates and availability response reflects only the specific number of nights. The basic search allows no alternate dates to be used, and thus no alternate rates to be discovered.
If a city search is performed (i.e., a search focusing on one city), this request is broken up into multiple searches for single hotels, and each such core hotel search is performed one at a time. The core search service doesn't recognize relationships between multiple hotels. Because every core request is performed one hotel at a time, with each request requiring complex business rules to be performed to find rates and availability, the cost of CPU time and resources is high. Additionally, given the CPU- and resource-intensive nature of each request, the response time can be relatively slow. The need to discover and compute rates and availability rules for every request takes time.
Also, in the prior art system, the request is very user-specific and does not allow for the transaction system to help discover alternate types of products, such as different room types, etc.
Perhaps the biggest disadvantage of the existing art is the single availability cell. The single availability cell is derived from a well defined Length of Stay (LOS) in the search request. The LOS is derived from the Start Date and End Date in the search request. There is no visibility for the multiple possible combinations that can be derived from the LOS in the search request. For example, if the requestor want to also evaluate different options with respect of the LOS, it will require several separate search request for each LOS option. The prior art does not provide flexibility of alternate dates or product items. The cost and the time required to build a reply with full flexibility is not cost effective at this time. For example: if a customer wants to check availability for the first week of May, 49 separate availability calls will be required. Seven availability calls for each day of the week (i.e. 7 days×7 LOS values per day). This transaction will increase the cost by a factor of 48 times (i.e. difference between 1 call and 49 calls), and will result a very long response time to the customer (i.e., a bad user experience).
There therefore exists a need in the art for improvements to travel and hotel transaction systems, as described in further detail below.